home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc735.txt < prev    next >
Text File  |  1994-08-01  |  11KB  |  295 lines
  1.  
  2. RFC 735                                          DHC RHG  3 Nov 77 42083
  3. Telnet Byte Macro Option
  4.  
  5.  
  6.  
  7. Network Working Group                                   David H. Crocker
  8. RFC: #735                                                       Rand-ISD
  9. NIC: #42083                                      (Dcrocker at Rand-Unix)
  10.                                                      Richard H. Gumpertz
  11.                                               Carnegie-Mellon University
  12.                                                    (Gumpertz at CMU-10A)
  13.  
  14. Obsoletes: RFC #729 (NIC #40306)                         3 November 1977
  15.  
  16.                     Revised TELNET Byte Macro Option
  17.  
  18. 1. Command name and code:
  19.  
  20.    BM 19
  21.  
  22. 2. Command Meanings:
  23.  
  24.    IAC WILL BM
  25.  
  26.       The sender of this command REQUESTS or AGREES to use the BM
  27.       option, and will send single data characters which are to be
  28.       interpreted as if replacement data strings had been sent.
  29.  
  30.    IAC WON'T BM
  31.  
  32.       The sender of this option REFUSES to send single data characters
  33.       which are to be interpreted as if replacement data strings had
  34.       been sent. Any existing BM <macro byte> definitions are discarded
  35.       (i.e., reset to their original data interpretations).
  36.  
  37.    IAC DO BM
  38.  
  39.       The sender REQUESTS or AGREES to have the other side (sender of
  40.       WILL BM) send single data characters which are to be interpreted
  41.       as if replacement data strings had been sent.
  42.  
  43.    IAC DON'T BM
  44.  
  45.       The sender REFUSES to allow the other side to send single data
  46.       characters which are to be interpreted as if replacement data
  47.       strings had been sent. Any existing BM <macro byte> definitions
  48.       are to be discarded.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.                                    1
  60.  
  61. RFC 735                                          DHC RHG  3 Nov 77 42083
  62. Telnet Byte Macro Option
  63.  
  64.  
  65.  
  66.    IAC SB BM <DEFINE> <macro byte> <count>
  67.                                              <replacement string> IAC SE
  68.  
  69.       where:
  70.  
  71.          <macro byte> is the data byte actually to be sent across the
  72.          network; it may NOT be Telnet IAC (decimal 255, but may be any
  73.          other 8-bit character.
  74.  
  75.          <count> is one 8-bit byte binary number, indicating how many
  76.          <replacement string> characters follow, up to the ending IAC
  77.          SE, but not including it. Note that doubled IACs in the
  78.          definition should only be counted as one character per pair.
  79.  
  80.          <replacement string> is a string of zero or more Telnet ASCII
  81.          characters and/or commands, which the <macro byte> is to
  82.          represent; any character may occur within a <replacement
  83.          string>. Note, however, that an IAC in the string must be
  84.          doubled, to be interpreted later as an IAC; to be interpreted
  85.          later as data byte 255, it must be quadrupled in the original
  86.          <replacement string> specification.
  87.  
  88.       The indicated <macro byte> will be sent instead of the indicated
  89.       <replacement string>. The receiver of the <macro byte> (the sender
  90.       of the DO BM) is to behave EXACTLY as if the <replacement string>
  91.       string of bytes had instead been received from the network. This
  92.       interpretation is to occur before any other Telnet
  93.       interpretations, unless the <macro byte> occurs as part of a
  94.       Telnet command; in this case no special interpretation is to be
  95.       made. In particular, an entire Telnet subnegotiation (i.e. from
  96.       IAC SB through IAC SE) is to be considered a Telnet command in
  97.       which NO replacement should be done.
  98.  
  99.       The effect of a particular <macro byte> may be negated by reseting
  100.       it to "expand" into itself.
  101.  
  102.       IAC SB BM <DEFINE> X <0> IAC SE may be used to cause X to be
  103.       ignored in the data stream.
  104.  
  105.       <DEFINE> is decimal 1.
  106.  
  107.    IAC SB BM <ACCEPT> <macro byte> IAC SE
  108.  
  109.       The receiver of the <DEFINE> for <macro byte> accepts the
  110.       requested definition and will perform the indicated replacement
  111.       whenever a <macro byte> is received and is not part of any IAC
  112.       Telnet command sequence.
  113.  
  114.  
  115.  
  116.  
  117.  
  118.                                    2
  119.  
  120. RFC 735                                          DHC RHG  3 Nov 77 42083
  121. Telnet Byte Macro Option
  122.  
  123.  
  124.  
  125.       <ACCEPT> is decimal 2.
  126.  
  127.    IAC SB BM <REFUSE> <macro byte> <REASON> IAC SE
  128.  
  129.       The receiver of the <DEFINE> for <macro byte> refuses to perform
  130.       the indicated translation from <macro byte> to <replacement
  131.       string> because the particular <macro byte> is not an acceptable
  132.       choice, the length of the <replacement string> exceeds available
  133.       storage, the length of the actual <replacement string> did not
  134.       match the length predicted in the <count>, or for some unspecified
  135.       reason.
  136.  
  137.       <REFUSE> is decimal 3.
  138.  
  139.       <REASON> may be
  140.  
  141.          <BAD-CHOICE>        which is decimal 1;
  142.  
  143.          <TOO-LONG>          (for receiver's storage) which is decimal
  144.                              2;
  145.  
  146.          <WRONG-LENGTH>      (of actual string compared with promised
  147.                              length in <count>) which is decimal 3; or
  148.  
  149.          <OTHER-REASON>      (intended for use only until this document
  150.                              can be updated to include reasons not
  151.                              anticipated by the authors) which is
  152.                              decimal zero (0).
  153.  
  154.    IAC SB BM <LITERAL> <macro byte> IAC SE
  155.  
  156.       The <macro byte> is to be treated as real data, rather than as
  157.       representative of the <replacement string>
  158.  
  159.       Note that this subcommand cannot be used during Telnet
  160.       subcommands, since subcommands are defined to end with the next
  161.       occurrence of "IAC SE". Including this BM subcommand within any
  162.       Telnet subcommand would therefore prematurely terminate the
  163.       containing subcommand.
  164.  
  165.       <LITERAL> is decimal 4.
  166.  
  167.    IAC SB BM <PLEASE CANCEL> <macro byte> <REASON> IAC SE
  168.  
  169.       The RECEIVER of the defined <macro byte> (i.e., the sender of IAC
  170.       DO BM) requests the sender of <macro byte> to cancel its
  171.       definition. <REASON> is the same as for the <REFUSE> subcommand.
  172.  
  173.  
  174.  
  175.  
  176.  
  177.                                    3
  178.  
  179. RFC 735                                          DHC RHG  3 Nov 77 42083
  180. Telnet Byte Macro Option
  181.  
  182.  
  183.  
  184.       The <macro byte> sender should (but is not required to) respond by
  185.       resetting <macro byte> (i.e., sending an IAC SB BM <DEFINE> <macro
  186.       byte> <1> <macro byte> IAC SE).
  187.  
  188.       If the receiver absolutely insists on cancelling a given macro,
  189.       the best it can do is to turn off the entire option, with IAC DONT
  190.       BM, wait for an acknowledging IAC WONT BM and then restart the
  191.       option, with IAC DO BM. This will reset all other macroes as well
  192.       but it will allow the receiver to REFUSE with code BAD CHOICE
  193.       if/when the foreign site attempts to redefine the macro in
  194.       question.
  195.  
  196. 3. Default:
  197.  
  198.    WON'T BM -- DON'T BM
  199.  
  200.       No reinterpretation of data bytes is done.
  201.  
  202. 4. Motivation for the option:
  203.  
  204.    Subcommands for Telnet options currently require a minimum of five
  205.    characters to be sent over the network (i.e., IAC SB <Option name>
  206.    IAC SE). For subcommands which are employed infrequently, in absolute
  207.    numbers and in relation to normal data, this overhead is tolerable.
  208.    In other cases, however, it is not. For example, data which is sent
  209.    in a block- oriented fashion may need a "block separator" mark. If
  210.    blocks are commonly as small as five or ten bytes, then most of the
  211.    cross-net data will be control information. The BM option is intended
  212.    as a simple data compression technique, to remove this overhead from
  213.    the communication channel.
  214.  
  215. 5. Description of the option
  216.  
  217.    The option is enabled through the standard Telnet Option negotiation
  218.    process. Afterwards, the SENDER of data (the side which sends the IAC
  219.    WILL BM) is free to define and use mappings between single and
  220.    replacement NVT characters. Except for the ability to refuse
  221.    particular definitions, the receiver of data has no control over the
  222.    definition and use of mappings.
  223.  
  224.    The sender (of the WILL BM) is prohibited from using or redefining a
  225.    <macro byte> until it has received an <ACCEPT> <REFUSE>, or DONT BM,
  226.    in reply to a <DEFINE>.
  227.  
  228.    NOTE: The Telnet command character IAC (decimal 255) may be a member
  229.    of a <replacement string> but is the ONLY character which may NOT be
  230.    defined as a <macro byte>.
  231.  
  232.  
  233.  
  234.  
  235.  
  236.                                    4
  237.  
  238. RFC 735                                          DHC RHG  3 Nov 77 42083
  239. Telnet Byte Macro Option
  240.  
  241.  
  242.  
  243.    Within any Telnet command (i.e., any sequence beginning with IAC)
  244.    macro replacement may NOT take place. Data are to be interpreted only
  245.    as their normal character values. This avoids the problem of
  246.    distinguishing between a character which is to be taken as a <macro
  247.    byte>, and interpreted as its corresponding <replacement string>, and
  248.    one which is to be taken as its usual Telnet NVT value. In all other
  249.    cases, however, <macro byte>s are to be interpreted immediately, as
  250.    if their corresponding <replacement string>s had actually been sent
  251.    across the network. Expanded strings are not subject to
  252.    reinterpretation, so that recursive definitions cannot be made.
  253.    Telnet commands may be included in <replacement strings>; however,
  254.    they must be totally contained within the macro or must begin within
  255.    the macro and terminate outside of it. In particular, they may NOT
  256.    begin outside a macro and continue or terminate inside one, since no
  257.    macro replacement takes place while processing any Telnet command.
  258.  
  259.    Note that when skipping data due to Telnet SYNCH (INS/DM) processing,
  260.    BM macro replacement should still take place, since (for example)
  261.    "IAC DM" would be a valid <replacement string>.
  262.  
  263.    The <count> in the <DEFINE> subcommand is intended to allow the
  264.    receiver to allocate storage. IAC interpretation is not over-ridden
  265.    during BM subcommands so that IAC SE will continue to safely
  266.    terminate malformed subcommands.
  267.  
  268.    The BM option is notably inefficient with regard to problems during
  269.    <macro byte> definition and use of <macro byte>s as real data. It is
  270.    expected that relatively few <macro byte>s will be defined and that
  271.    they will represent relatively short strings. Since the Telnet data
  272.    space between decimal 128 and decimal 254 is not normally used,
  273.    except by implementations employing the original (obsolete) Telnet
  274.    protocol, it is recommended that <macro byte>s normally be drawn from
  275.    that pool.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.                                    5